Before jumping into managing federated delegation and a discussion of the various scenarios, let's start out with an overview of federation, its challenges, and its implementation in Exchange Server 2010.
Overview of Federation and Federated Delegation
Federated delegation
in Exchange Server 2010—and the underlying federation infrastructure
with the Microsoft Federation Gateway—is an innovative means of
securely sharing information with external recipients with minimal
management overhead compared with traditional federation technologies.
A common request is for end users to determine the availability of
users in other organizations when planning meetings, short of calling
them on the phone and asking them what times work for them.
1. Federation Overview
For Star Trek fans,
federation may have a different meaning, but for the purposes of this
discussion federation is used in the context of federated identity. Federated identity
means a user's authentication and authorization process across multiple
IT systems (or Exchange organizations, in our case). It can also refer
to the assembling of a user's identity from disparate identity
management systems, but for the purposes of this discussion we are
concerned with authentication and authorization.
Federation is a
claims-based means of providing secure Web-based authentication and
authorization across organizations and platforms without needing to
replicate or reproduce the user's identity or attributes (referred to
as "claims," such as e-mail address, UPN, display name, and so on) in
another directory or other information silo. This means that a user can
perform single sign-on (SSO)
across organizational boundaries without the need for directory or GAL
synchronization, or learning another set of credentials, or needing to
have the other organization store and manage replicated credentials or
directory objects. A user's identity, e-mail address, and other
requested attributes are asserted as claims in tokens, which are
presented to an application to verify the user and the user's
attributes. Microsoft's federation implementation, Active Directory
Federation Services (AD FS), was first introduced in Windows Server
2003 R2 and is based on the industry standard WS-Federation
specification, which is part of the WS-* Web Services Architecture.
In a typical
deployment, federation was enabled between organizations through each
organization standing up a federation infrastructure and then
establishing a secure federation trust between them. These federation
trusts are conceptually similar to Active Directory forest trusts in
that a trust was established between the organizations to allow one
organization to trust authentication tokens issued by the other
organization. In reality, a federation trust is Web-based and is
enabled through the sharing of public keys between the organizations,
unlike Active Directory trusts. In addition, because it is Web-based, a
federation trust requires only port 443 communication between the
components.
Because these federation trusts
are at the organizational level, every organization must create a trust
with every other organization. This means that to establish trusts with
multiple organizations, (n*(n–1)) trusts are required, where n represents the number of organizations involved. This is illustrated in a configuration involving four organizations in Figure 1.
As you can see, the standard federation deployment shown in Figure 10-1
means that the configuration and management of a large number of trusts
can quickly become unwieldy as more organizations are involved,
requiring you to share your public keys with each organization you have
a trust with, and maintain their public keys in your organization.
2. Role of the Microsoft Federation Gateway
To simplify this management challenge, Exchange Server 2010 uses the Microsoft
Federation Gateway (MFG) as a trust broker. The Microsoft Federation
Gateway is an identity backbone that runs in the cloud, acting as a hub
for federation activity between (in this case) Exchange Server 2010
organizations. This means that you only need to create one federation
trust with the Microsoft Federation Gateway rather than with each
organization you want to establish a relationship with. To establish a trust with the Microsoft Federation Gateway service,
your organization must obtain an X.509 certificate from a third-party
certificate authority (CA) as well as verify their ownership of the
domain they are federating by publishing an application identifier (appID) in a TXT
resource record in the DNS zone for that domain.
Note:
It
is important to point out that the Microsoft Federation Gateway acts as
a broker service (intermediary) only; no credentials or passwords are
stored there and no Windows Live accounts are necessary for its use.
Its only function is to facilitate the federation trust to enable
organizations to share information securely without needing to
establish individual trusts between each other.
After you have created a
single federation trust with the MFG for your organization, you simply
configure an organization relationship with another organization to
enable you to start sharing information securely; you don't need to
exchange any certificates or metadata with the other organization.
